![【レポート】「第12回Ques」に参加してきました #ques12](https://devio2023-media.developers.io/wp-content/uploads/2018/11/yoshim_ques12_participation_report_1.jpg)
【レポート】「第12回Ques」に参加してきました #ques12
2018年11月16日(金)に開催された 「第12回Ques」 に参加してきましたので、まとめレポートを書こうと思います。
今回は「AI時代の品質」をテーマに、AIについて「テストの視点」からの報告がメインとなりました。
まだ一部の資料を取得できていないので、取得でき次第添付します。
目次
1.「Ques」について
私も今回始めて知ったイベントなのですが、こちらに「Quesとは?」というズバリなページがあったので、それを引用します。
Quesとは、Software品質保証に関わるQAエンジニアの活性化を目的としたQA専門のイベントです。 Software品質保証に関わるQAエンジニアの方が、会社間の垣根を越えて、情報交換や交流を深めてもらう事で、日本のSoftware品質保証を盛り上げていく場にしたいと思います。
ちなみに、呼び方は「キューズ」です。 今後も年に2回(5,11月)実施していく予定とのことです。
ちなみに、今回はノベルティとしてハイチュウもいただけました。
今回のノベルティはハイチュウです #ques12 pic.twitter.com/UNEr3KqJA4
— Quesの中の人 (@Ques_staff) 2018年11月16日
2.挨拶
まずは、「Ques事務局」の「宮本 由布樹」さんから簡単にご挨拶があり、「Ques」の今までの経緯や、Quesブログについてのご紹介がありました。
(画質が悪いです...)
Quesブログは「QA(Quality Assurance)」に関する記事が多く、品質保証に興味のある方は一度見てみるといいかもしれません。
3.自動テスト × 機械学習 ~自動テスト結果分析は楽になるか?
続いて、「株式会社ヒューマンクレスト」の「山口 真央」さんの報告です。
「自動テストに機械学習を組み込んだ事例」という私が聞いたことがない領域の話だったので、とても面白かったです。
Quesブログのご講演者インタビューもアップされていますので、よろしかったらこちらもご覧ください。
もしよかったらスライドもご参照ください。
●テーマの経緯
自動テストでは、「結果の分析が大変」、「自動テストを作っている人がいなくなると、そのシステムが使えなくなる」といった問題を抱えており、 「より自動テストの結果分析を簡単にできないか?」という目的のもと、下記の2パターンを試したとのことです。
- レイアウト崩れ自動検知
- 自動テスト結果分析
●レイアウト崩れ自動検知の経緯
この検知は、「従来手動でやっていた作業をより簡単にできないか」、「会社で提供している自動化サービスに対して、お客様からレイアウトチェックもできないかと相談されていた」といった背景から取り組んだそうです。
従来から社内でも「OpenCV」を使ってレイアウト崩れチェックのテストはしていたものの、このやり方ではまだまだ課題(ex.サイトのデザイン変更,広告の投入等があったらエラーになる)が残っていたため、「画像1枚だけでテストできたらいいのに」という考えがスタートラインになったそうです。
より具体的には、レイアウトが崩れている箇所について、「位置」、「どのくらい崩れているか」を取得すること、をゴールとして設定したそうです。
●技術要素と実施事項(レイアウト崩れ自動検知経緯)
実際に利用した技術要素についても説明してくださいました。
まずは、「レイアウト崩れした画像を集める」ところから始め、下記の5点を試してみたそうです。
当日の報告では、この5点のうち下記の2点をピックアップしてお話しくださいました。
要素・位置からレイアウト崩れを検出
- OpenCVで要素を抽出。
- 抜き出した要素が「何か」を機械学習で分類。
要素の分類はできそうだが、データが不足していたため結果が安定せず、「レイアウトが崩れると領域の抽出がうまくいかない」ということがわかった段階でこの手法は一旦保留としたそうです。
1枚の画像からレイアウト崩れ検出
- 1枚の画像とレイアウトを比較して「OK/NG」を返すことを目的として実施。
- 推論をする前に、「スクリーンショットをリサイズ」していたのだが(モデル生成時に利用した画像のサイズと合わせる必要があるため)、その時点で「レイアウト崩れ」かどうかが人間でわかるレベルなので、実質意味がない、という気づきを得たそうです。
●課題
ここまでの振り返りとして、下記の事柄が課題として判明したそうです。
また、「機械学習でできることの整理」ができていないと辛いところがある、とのことでした。
- 「レイアウト崩れしている画像」の収集が難しい(「puppeteer」を使って無理やり収集したが、無理がありそう)
- 「レイアウト崩れ」の判定に時間がかかる
●自動テスト結果の分析
続いて、「自動テスト結果の分析」に対して機械学習を活用した事例の紹介に移りました。
背景としては、エラー発生時の「一次切り分け」(ex.原因が「環境」、「タイムアウトエラー」、「不具合」のいずれなのか)が大変なので自動化したい、といったものだそうです。
「レイアウト崩れ自動検知」の時とは異なり、今回はデータを集める仕組みができていたので、それをうまく使えないか、と考えたそうです。
(Lynxというサービスを提供しており、ここにデータを貯めていた、とのことです)
●INPUT,OUTPUT等のデータ周りについて
自動テストの「シナリオ」、「設定」をINPUT、「エラー情報等」をOUTPUTと定義しました。
また、利用するデータについては、3年半分のデータがあったものの、全期間のデータを機械学習でやるのは難しく、また傾向も変わっているため、使うデータを絞ったとのことです。
また、全体のデータの傾向を確認した結果、「エラーの報告結果が色々なところに分散して存在している。(slack,gmail,レッドマイン,lynx等)」、「必要な情報が不足していた」ことがわかり、「データ設計の頃からしっかりやっておいた方がよかった」といった振り返りが得られた、とのことです。
●説明変数について
下記のような説明変数を利用したそうです。
●データ分析結果
全体を一気に見ても要点が把握しづらいので、データを絞って分析したそうです。
「AWS、社内ローカル環境のどちらで実行した方がいいのか」、というのが前から気になっていた、という背景から、AWSとローカルでの「テスト結果比較」をしてみたところ、特に差異はないことが分かったそうです。
続いて、「ブラウザごとの比較」をしてみたところ、「成功率はそこまで変わらない」、「IE11は実行時間が長い」といったことが分かったそうです。
●各ステップ毎の実行時間予測
普段から「タイムアウトエラーが多い」、というのを感じていたことから「ステップごとの実行時間予測」を試したそうです。
もし実行時間が予測できれば、適切な待ち時間を指定することでエラーが減り、その結果テスト結果分析の数が減る、という流れを想定していらっしゃいました。
今回はPythonの一般的な機械学習ライブラリである「sklearn」で5つのモデルを試したそうです。
各モデルの結果を比較したところ、「RandomForest Regressor」が一番良い結果がでたものの、「まだ誤差が大きい」とのことでした。
●今後の課題
「データが一番大事」ということを実感し、まずは「データ収集の仕組み」を作るところを、いずれは「画面崩れ検知」に再挑戦したい、とのことでした。
また、「色々やったけどまだ難しくて、半年くらいやってまだ少しだけなんとなくわかってきた、というくらい」という感想もおっしゃっていました。
機械学習については「実際にやってみてわかることも多い」と私も感じているので、この感想にはただただ共感するばかりです。
●Q&A
最後にQ&Aがあったので、いくつか質問をピックアップしておきます。
Q:テスト設計自動化に役立てたい、ということはすでに何らかのビジョンがあるかと思うのですが、さわりだけでも教えていただけないでしょうか?
A:自動テスト結果を役立てたい、とは考えているが細かいところはこれから考えていきたい
Q:「待機時間の予測」について、「タイムアウトエラー」対策としてはElementを使えば良いのでは?
A:今後はElementを使う予定です
Q:「レイアウト崩れ」について、「崩れている箇所」を検出して、「そこがどれだけ崩れているか」を予測すれば良いのでは、と思うのですがいかがでしょうか
A:それについてはある程度取り組もうとしていたので、もう少ししっかり取り組んでいけたら、と思っています。
4.AIのテスト ~画像認識における誤検知と検出漏れ
続いて、「株式会社クロノス」の「大石 宏一」さんの報告です。
「AIを内包したプロダクトにおける品質とは」について改めて考えさせられる内容でした。
Quesブログのご講演者インタビューもアップされていますので、よかったらこちらもご覧ください。
また大石様の登壇資料については、こちらをご参照ください。
●会社紹介
まずは「株式会社クロノス」さんの紹介からです。
「株式会社クロノス」さんはAIやアプリの開発に携わっており、「AI×Data活用研究会」を主催しているそうです。
●品質のあるべき姿
品質基準がないところが多く、ウォーターフォール形式で要件定義等に落とし込んでいるうちに「客の課題解決」から離れていくことが問題であり、現代におけるプロダクトでは、「欠陥がないだけではなく、品質特性を実現できていることが必要」である。
また、日経BPが調査した結果で、今までは「品質」と言っていた項目が「満足度」という名前に変更されていることからも、「考え方を変化するターニングポイントに来ており、顧客の課題に正面から向き合える時代がきた」と大石さんは考えておられるそうです。
また、AIは「やってみないとわからない」という特徴から、ウォーターフォール系ではなくアジャイル的な取り組み方でないと合わない、とのことでした。
●事例概要
実際に「清掃会社でAIを内包したアプリ」の活用事例を紹介してくださりました。
この業界は差別化が難しく、「AIを使って差別化したい」、というインセンティブから始まったそうです。
そこで、清掃員がスマホで動画を撮って、AIがゴミを検出し、地図上に「どこに何がどのくらいあった」というのをヒートマップで表示するアプリを開発したそうです。
●品質担保の方針
機械学習のコードはそこまで長くないので、「そもそもバグが入りづらい」ものです。そこで、「AIの品質」を「目的に沿った精度がどれだけ出せるか」ということで評価することとしたそうです。
例えば、物体検出アルゴリズムでは「誤検知と検出漏れはトレードオフ」1になることが多いため、一言で「精度」と言っても難しいものなのですが、今回の清掃会社の場合は「取りこぼしを減らしたい」とのことなので「多少の誤検知があろうが、検出漏れを減らす」方針にしたそうです。
●モデルの生成過程
続いて、実際にどのように開発作業を進めたのか、という報告に移りました。
まずは社員総出で3週間かけてデータを収集し、拡張したデータセット等を含めて様々なモデルを生成してみたそうです。
モデル生成のアルゴリズムには「Tensorflow Object Detection API」を活用したそうです。
データは「zipファイル」で貯めてからバッチ処理とし、最終的な精度は80%程度まで出たそうです。
また、ここで精度向上を追求するのではなく、「UIで解決する」方針を目指し、顧客と検出の閾値について交渉し、リリースに至ったそうです。
この舵きりも「品質」を「顧客の満足度」として考えた結果、とのことです。
●Q&A
最後にQ&Aがあったので、いくつか質問をピックアップしておきます。
Q:清掃会社がヒートマップを使って解決したかった課題は?
A:会社に依頼を出す行政側が「費用対効果」を把握しやすくする。いつもどこにゴミが溜まっているのか、というのがわかるので「ゴミ捨て禁止の看板」や「タバコの灰皿立てをここに設置したらいい」とか、ゴミ削減の対策方針の検討に役立つ。
Q:具体的にはどのような話の流れになったのか
A:お客様から課題を伺った後に、AI推進担当者が考えたものを提案しました。基本的にお客様のニーズに合わせてカスタマイズすることが多いです
Q:地方と都内でゴミの内容が異なると思うが、それで誤検知とかはなかったのか
A:ありました(ex.コンクリート上のゴミ、公園とかに落ちているゴミ)。今回の検証では全て「東京」で集めたデータでやりました。
Q:品質基準が設けられていない、とあるが今回の事例での「品質基準」は何か
A:お客様の「満足度」です。感想をもらって、測る形になります。
5.懇親会
セッション終了後は懇親会に移りました。
お酒やおつまみを提供していただき、色々な方とお話しすることができました。
6.まとめ
機械学習の勉強会にはちょこちょこ参加しているのですが、「品質」をメインとしたイベントは凄く貴重であり、とても参考になりました。
機械学習のシステムを運用している方々の参考になれば幸いです。
-
「誤検知と検出漏れはトレードオフ」についてざっくりと説明します。
今回機械学習で利用したモデルは「物体検出」という「画像中の、どの部分に、○○がある、という確率がどれくらいか」という結果を返すものなのですが、最終的に活用する時はこの確率の部分に「閾値」を設定することになります。(ex.△%以上の確率のもののみを採用する)
この閾値を高く設定しすぎると、検出漏れが発生しやすくなる一方で「誤検知」は減ります。逆に、閾値を低く設定すると検出漏れは減るものの、「誤検知」が増える可能性があります。この閾値については「最終的に到達したい目的」に基づき設定する必要があります。 ↩